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R ecent work on frameworks 1 ^ 4 depicts the advan¬ 
tages of components and frameworks in general. 
Developing a system architecture consisting of 
components and subsystems is an excellent idea from the 
modular design and software maintenance points of 
view. In this article, I will show how construction of 
Smal Ital k I ink I ibraries (SLLs) aids in mai ntai ni ng a devel¬ 
oped application and delivering component-oriented 
software. I will describe a way to ship a Smalltalk applica¬ 
tion by creati ng SLLs. Each SLL can represent a subsystem 
or a specific component in your application. The process 
of Smalltalk library construction makes a developer real¬ 
ize the framework benefits at the ti me of del i very. 

The code examples described are based on Digitalk 
Smalltalk/V Version 3.0.1 for OS/2 PM (Presentation 
Manager), but the same concept can be tailored to the 
Smalltalk/V Windows environment. This example also 
demonstrates how Smalltalk takes advantage of host 
operating system features for the application delivery. 
Example code can be obtained on the World Wide Web at 
http://www.objectpeople.on.ca/software. 

SMALLTALK APPLICATION PACKAGING AND 
MAINTENANCE 

It is a well-known fact that once the learning curve barri¬ 
er is overcome, a Smalltalk developer becomes proficient 
in writing Smalltalk programs and the development task 
becomes fairly easy. In large projects, a considerable 
amou nt of ti me may be spent produci ng and mai ntai n i ng 
a good executable i mage. Ful l-ti me resources may need to 
be allocated to perform this task. As the executable image 
size begi ns growi ng, a Smal Ital k developer may hear com¬ 
ments about havi ng a "fat" executable. Everybody expects 
a nicely trimmed executable for application delivery. 
There is absolutely nothi ng wrong with this expectation; it 
is easier to manage a smaller executable during applica¬ 
tion shipment. However, some momentum gained in 
developing Smalltalk applications can be lost in the 
process of constructing and delivering a Smalltalk exe¬ 
cutable. 

Once development is complete, the organization 
begi ns a testi ng phase. As a resu It of code enhancements, 


code optimization, bug fixes, etc., code tuning begins as 
per feedback and suggestions of users. Often, these 
changes are specific to particular subsystem classes 
and/or methods, and classes and/or methods in other 
su bsystems are not affected. Because the Smal Ital k i mage 
(which uses v.exe, changelog, and recover.log files) is not 
partitioned, there is no way to focus the efforts on partic¬ 
ular subsystem classes or methods to carry out code tun¬ 
ing. Here, SLLs come to the rescue. The organization can 
create a Smalltalk image that consists of SLLs for each of 
its subsystems and use them as needed, or distribute 
them appropriately to clients to satisfy client require¬ 
ments These SLLs are used either in a development or 
runtime environment as per one’s needs SLLs are very 
handy for accelerating the overall application packaging 
task and maintai ni ng the Smal Ital k appl ication. 

A REAL-LIFE EXAMPLE 

Assume that an organization has developed a software 
framework to satisfy its business needs. Consider a simple 
situation where this framework uses a dependency mech¬ 
anism (i.e., the user interface is dependent on a business 
model) and is comprised of two subsystems including a 
business model subsystem (to contain business state and 
business logic) and a user interface subsystem (to display 
business model data), etc. In reality, framework imple¬ 
mentations may contai n other subsystems such as a rule 
model subsystem (to handle business rules), an applica¬ 
tion model subsystem (to handle behavior related to the 
application model), a communication model subsystem 
(to handle message send/receive), a database subsystem, 
etc. Classes in these subsystems collaborate with each 
other appropriately per their responsibilities to provide 
the behavior specified by the framework. 

Also assume that there is a client base of this organiza¬ 
tion that wants to use the framework-level classes (i.e., 
high-level abstract superclasses) from these subsystems to 
ensure they comply with the overall organization frame¬ 
work. In addition, they want to utilize both framework- 
level and concrete-level classes in an existing business 
model subsystem, and customize their user-interface 
model differently than the one used bytheorganization. 
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Until recently,fewoptionswereavailabletohandlethis 
situation. If the organization and its clients were using 
just a Smalltalk(withoutTeam/V) environment, then the 
only option was for the organization to give its cl ients the 
whole Smalltalk image, containing the base Smalltalk 
image, user-interface classes (abstract superclasses), and 
business model classes (framework- and concrete-level 
classes). If the organization and its clients were using 
Smal Ital k with Team/ V, then clients couId access busi ness 
model subsystem classes using the individual "package 
migration" technique 5 or by creating specific tools (visual 
or textual) on top ofTeam/Vto handle "migrating a list of 
packages." These approaches are on the verge of obsolete 
for a variety of reasons including limitations encountered 
during application packaging and maintenance phases; 
the Parcplace-Digitalk merger, which is resulting in a new 
architecture; and an overall industry shift toward compo- 
nentware. 

DYNAMIC LINK LIBRARIES AND SLLs 

OS/2 provides a powerful way of bundling your applica¬ 
tion program into a coherent unit called a dynamic link 
library (DLL). As the name suggests, a DLL provides ser¬ 
vices that are accessed and linked dynamically by differ¬ 
ent application programs. It provides a way for an appli¬ 
cation program to dynamically reference and access func¬ 
tions and resources outside its own executable environ¬ 
ment. 6 Such resources might be icons, bitmaps, or point¬ 
ers, etc., whereas functions could be the PM application 
programming interface (API) calls for handling window 
management, graphics, device driver routines, or access¬ 
ing OS/2 executable programs, etc. Smalltalk/V PM with 
the use of SLLs takes this concept one level higher, allow¬ 
ing one to access the services provided by individual sub¬ 
systems By tapping the power ofOS/2’sDLL mechanism 
underneath it, Smalltalk/V PM allows one to create SLLs 
of classes, methods, and metaclasses that can be shared 
bydifferentteamswithin an organization. Object libraries 
were a common means of building DLL files in Digitalk 
Smalltalk previous to Version 3.0.1. SLLs are those object 
libraries with a new face. 

DELIVERING A SMALLTALK APPLICATION 

In Smalltalk/V PM, the Smalltalk image consists of the 
executable environment (v.exefile, changeJogfile, recov- 
er.log file), one or more DLL files, and one or more SLLs. 
DLLs are divided into base class DLLs and development 
dassDLLs. Base class DLLs contain classes such ascollec- 
tions, streams, windows, etc., whereas development class 
DLLs contain the Smalltalk compiler, debugger, etc. 6 A 
Smalltalk programmer uses the development classes to 
create a Smalltalk application program. As development 
progresses, the code created by the programmer (once 
saved) is added into the v.exe file, which begins to grow. 
Typically a programmer uses the v.exe file to deliver 
the application. This approach works well whether the 
design contains a relatively small or large number of 
classes. Then, by making appropriate changes in the 


#startllpAppiication method in the NotificationManager 
class, the programmer uses v.exe to start the application. 
This standard approach always works. 

Another way to deliver a Smalltalk application is filing 
out all the classes from one programmer’s image and 
installing them on another programmer's image. 

Both approaches are cumbersome from the applica¬ 
tion maintenance point of view. A better way is to build 
Smalltalk libraries of classes to provide flexibility in deliv- 
eri ng Smal Ital k appl ications. 

DIFFERENT WAYS TO CONSTRUCT SLLs 

Before transferring the executable to users, programmers 
test their applications to confirm that they meet require¬ 
ments It might be a good idea to start building SLLs at the 
initial application development phase, to ease the future 
maintenance task. Such SLLs can be loaded in a develop¬ 
ment or runtime environment. Here, the task of Smalltalk 
library construction can be accomplished in a variety of 
ways. One could categorize it based on different aspects 
such as the existing services, different subsystem frame¬ 
works, or available standalone classes (explained next). 
Referring back to our example, assume that a simple busi¬ 
ness model for the organization consists of classes such as 
Person, Address, HomeAddress, BusinessAddress, Phone, 
HomePhone, BusinessPhone, etc., while the user-interface 
model consists of classes such as UserlnterfaceModel, 
Userl nterfaceModelForOrganization, and Person 
InformationWindowDialog (to display Person information). 
Combined, these different classes could provide a "view" 
service that enables oneto view information about persons. 

Construction based on the service behavior 

The organization could treat the aforementioned busi¬ 
ness model and user-interface classes as one entity, and 
construct a single Smalltalk library representing a Person 
information "view" service, i.e., construct one Smalltalk 
library that contains business model subsystem classes 
(abstract and concrete) and user-interface subsystem 
classes (abstract and concrete) to provide this specific ser¬ 
vice. If the organization needs a "change" service, consist¬ 
ing of additional user-interface classes such as 
ChangePersonl nformationDialog (to change the Person infor¬ 
mation) and other business objects created to handle 
the changes, the organization could then construct 
another Smalltalk library representing a "Person informa¬ 
tion change service." In general, this approach facilitates 
d evel o p ment effo rts w i th i n the o rgan i zati o n. 

Smal Ital k I i brary for vi ew service: 

BusinessModel Subsystem (abstract and concrete 

classes) and UserlnterfaceModel Subsystem Smalltalk 

Library (abstract and concrete classes related to view¬ 
ing the person) 

Smal Ital k I i brary for change service: 

BusinessModel Subsystem (abstract and concrete 
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classes) and UserlnterfaceModel Subsystem Smalltalk 
library (abstract and concrete classes related to chang¬ 
ing the person information) 


Construction based on framework implementation 

In construction based on framework implementation, the 
organization treats the aforementioned business model 
classes and user-i nterface classes as two different entities 
and constructs two separate SLLs. Thus, by constructing 
two SLLs for business model subsys¬ 
tem classes (abstract and concrete) 
and user-interface subsystem classes 
(abstract classes), the organization 
creates a server environment that 
provides services such as knowing 
the state of the busi ness objects and 
providing user-interface protocols to 
display the current state of the busi¬ 
ness objects. The organization and its 
client base use this server environment to customize 
user-interfaces appropriately. In general, this approach is 
best used when the organization has to satisfy client base 
requirements 

Server SLLs: 

BusinessModel 
Subsystem 
Smalltalk library 

Client SLLs: 

UserlnterfaceModel Subsystem Smalltalk 
I i brary (concrete classes for organization) 

UserlnterfaceModel Subsystem Smalltalk 
I ibrary (concrete classes for clients) 

Construction based on standalone classes 

One can construct a Smal Ital k I i brary of standalone class¬ 
es that don’t belong to a particular subsystem but are 
required by different subsystems, such as classes for man¬ 
aging application configuration, setting application envi¬ 
ronment, other helper classes, etc. This Smalltalk library 
can then be treated as a standalone component in the 
application. 

CREATING A BUSINESS MODEL SMALLTALK LIBRARY 

Assume that the organization follows the second ap¬ 
proach to constructing a Smalltalk library, which results 
i n thei r havi ng two DLLs—one for busi ness model cl asses 
and one for user-interface classes. 

The typical steps to create a business model Smalltalk 
library are described below: 

1. Open the Library Builder dialog. Select the package 
containing business model subsystem classes. Select 
the following menu option: Module — >B u i I d Library. 

2. TheLibraryBuilderdialogofferstwooptionsCustomize 
theclasses that you would like to add into the library by 
clicking on theCustomizeoptionorjust let create an SLL 
for the classes contained within the selected pack¬ 


age/cluster. Also, onecan optionally includethe source 
codefor classes not in SLL one is creating. 

BINDING SLLs TO A SMALLTALK IMAGE 

The Digitalk help manual describes three ways to package 
Smal Ital k appl ication usi ng SLLs; these approaches let the 
developer bind SLLs statically or dynamically. 

The first approach is to bind SLLs during startup by 
including their names in an autobind ascii file, e.g„ 
app.bnd (during development image, it looks for 
vdevo.bnd file). This approach per¬ 
mits one to save the image without 
bi ndi ng it with the SLL, thus avoi di ng 
having to bind the SLL to a specific 
version of v.exe. 

The second approach is to bind the 
SLL dynamically. The developer can 
then bind and unbind SLLs on 
demand, which results in low memo¬ 
ry overhead. 

Finally, onecan bind SLLs in a hybrid way using a com¬ 
bination of the aforementioned two approaches: binding 
some SLLs to the i mage and bi ndi ng others dynamical ly. 

ADVANTAGES OF USING SLLs 

1. Data shari ng—M ulti pie applications access and share 
subsystem SLLs. A server environment is created by 
storing different SLLs on the network. AlI teams withi n 
the organization would then have ready access to it so 
that consistent access is maintai ned. Thus, SLLs make 
data sharing a transparent process across multiple 
applications. 

2. Pluggability— Modular components are created to 
enhance reusability. Thus, the maintenance task 
becomes flexible. This aids easy replacement and 
shi ppi ng of appropriate subsystem DLLs. 

3. Application of the producer/ consumer concept—This 
key concept of componentware (producing and con¬ 
suming the components) is easily adopted and applied. 
Ref erri ng to the example at the begi nni ng of this article, 
the organization becomes a producer of SLLs and the 
client base becomes a consumer of SLLs. 

4. Decreased imagesize—This conserves hard diskspace 
and reduces v.exe size, resuitingin less overhead. 

5. Flexibilityof usefortheorganization and itsclients— 
Oncethe busi ness model Smalltalk library iscreated, it 
is ready for distribution to theclient base, as well as use 
by the organization itself. The client base, which is 
uninterested in the user interface Smalltalk library 
(containingclassessuchasUserlnterfaceForOrganization, 
its subclasses, composite panes used in dialogs, etc.), 
can load the business model Smalltalk library in their 
development/runtime environment and begin using it 
alone. 

6. Creation of standalone class libraries—Components 
consisting of standalone classes are constructed and 
distributed appropriately. 

7. Realization of the framework benefits—During the 


The task of Smalltalk 
library construction 
can be accomplished 
in a variety of ways. 


U serl nterfaceM odel 
Subsystem 
Smalltalk library 
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design phase, classes (both framework- and concrete- 
level) are logically grouped to form a subsystem based 
on the i ntended behavior that a subsystem issupposed 
to perform. The correct decision to group a certain 
cl ass i n a parti cu I ar su bsystem aids the task of bu i I d i ng 
and maintainingSLLs. 

8. Construction simplicity—Previous Digitalk Smalltalk 
versions used the concept of object libraries, and 
Smalltalk developers spent a lot of time constructing 
them. On the other hand, SLLs are constructed simply 
and quickly. 

9. Platform portability between OS/2 and Win32 operating 
systems—SLL uses a unique and system-independent 
format. 7 Hence, it is easier to 
create appl icationsthat are port¬ 
able between these two 
platforms. 

10. Use in runtime and develop¬ 

ment environments—Works 
excellently in both runtime and 
development Smalltalk 

environments 

11. Scripting—During a release 
phase, a particular Smalltalk 
library may have to be reconstructed many times. By 
taking advantage of scripting facilities,? the task of 
constructing SLLs is simplified by creating scripts to 
reconstruct SLLs. 

DISADVANTAGES OF USING SLLs 

1. Difficult to use in a Team/V development environ¬ 
ment—If you load a Smalltalk library in a Team/V 
development environment, it loadsall the cl asses in the 
"unpackaged" package and not where they belong. 
Because most of the source code related to Team/V 
classes is hidden, it is difficult to ascertain how to 
replicate the "Load/Migrate" action (which loads all 
the classes in a particular package/cluster in one’s 
Smalltalk image) during Smalltalk library loading so 
that cl asses includedinthe Smal Italk library will fall into 
packages where they belong. 

2. Inability to extend existing Smalltalk library envir¬ 


onment—To build a Smalltalk library, Digitalk uses a 
few classes (SmalItalkLibrary, SmalItalkLibraryBind, 
TeamVLibraryl nformation, TeamVInterface, etc.) whose 
implementation is hidden to the developers Because 
they cannot access the code associated behind the 
methods, they cannot add any enhancements to base 
Smal Ital k I i brary cl asses. 

CONCLUSION 

This article reviewed different approaches to constructing 
SLLs and descri bed advantages to faci I itate the Smal Ital k 
application delivery task. It provided shared transparent 
access to different teams by conserving hard disk space. 

I found that the ability to create 
SLLs provides a pluggable 
approach that facilitates applica¬ 
tion maintenance tasks. The article 
also showed how with this 
approach, the momentum gained 
in developing Smalltalk applica¬ 
tions is retained while delivering 
Smalltalk applications. 
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